From 09c856316d67045d170679b6980f34348e4c402f Mon Sep 17 00:00:00 2001 From: Jan Beulich Date: Wed, 16 Apr 2014 18:18:35 +0200 Subject: [PATCH] x86: fix instruction emulator test's xgetbv constraints The "A" constraint, while documented up to gcc 4.5 as "The a and d registers, as a pair (for instructions that return half the result in one and half in the other)," never really behaved that (natural) way, but always meant (and is now also documented so) %eax _or_ %edx (%rax _or_ %rdx on x86-64) unless the operand was wide enough to require both (i.e. more than 32 bits on ix86 and more than 64 bits on x86-64). Interestingly something internal to the compiler changed between 4.4 and 4.5 to actually expose the difference - up to gcc 4.4 I was unable to construct a case where, when only the low half of the result is actually looked at, the result would be considered to be in %edx/%rdx (and %eax/%rax would be treated as unmodified by the instruction). Signed-off-by: Jan Beulich Acked-by: Keir Fraser Tested-by: Don Slutz --- tools/tests/x86_emulator/test_x86_emulator.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/tests/x86_emulator/test_x86_emulator.c b/tools/tests/x86_emulator/test_x86_emulator.c index 17b674b35c..0a00d5a4dc 100644 --- a/tools/tests/x86_emulator/test_x86_emulator.c +++ b/tools/tests/x86_emulator/test_x86_emulator.c @@ -102,11 +102,11 @@ static int cpuid( static inline uint64_t xgetbv(uint32_t xcr) { - uint64_t res; + uint32_t lo, hi; - asm ( ".byte 0x0f, 0x01, 0xd0" : "=A" (res) : "c" (xcr) ); + asm ( ".byte 0x0f, 0x01, 0xd0" : "=a" (lo), "=d" (hi) : "c" (xcr) ); - return res; + return ((uint64_t)hi << 32) | lo; } #define cpu_has_avx ({ \ -- 2.30.2